Access and visibility problems across Atlassian Cloud were resolved by restoring correct Atlassian account mappings, product access/licenses, project memberships/roles and ownership. Incidents were cleared after assigning the appropriate Atlassian product access or Jira license (license activations typically propagated within minutes up to ~40 minutes; licenses provisioned via centralized systems such as IUAK required the same propagation and sometimes a follow-up confirmation with the user). Project- and board-level visibility returned after adding users or groups to projects, assigning correct per-project roles and permission-scheme rights (examples included Create Issues, Assign Issues, Edit Issues, Delete Issues, Link Issues, Move Issues and Manage Sprints), explicitly granting board/plan sharing (Advanced Roadmaps required individual plan sharing), and transferring or reassigning board and dashboard owners so remaining users could manage and share them; several cases required administrators to perform owner-only changes. Pending invitations and approval-based flows repeatedly blocked links and were cleared when the invitation/approval completed. Attachment and upload failures were traced to missing project edit/attachment permissions and resolved by restoring roles that included those rights. Connected apps and embedded integrations failed when Atlassian account mappings were incorrect; resolutions included re-mapping accounts, re-enabling external accounts, granting webhook/integration rights to the integration, or having administrators create the Jira-side webhooks for the integration. Several users regained access immediately after clearing cookies/cache and re-authenticating via the IdP or opening Atlassian from the IdP dashboard. Temporary elevated rights were applied in some cases to perform owner-only changes when necessary.

Projects, boards and Confluence spaces were created, converted, deleted or reconfigured to meet requesters’ needs and to work around product limitations. Support clarified the functional differences between team-managed and company-managed (classic) projects — notably that team-managed custom fields and board configuration are project-local, and that non-admins can typically create only team-managed projects while global Jira admins can create company-managed projects. Incorrectly created projects were removed when requested and, where company-managed capabilities were required, support created company-managed projects, replicated board and project settings, granted board admin access, and moved open issues into the new projects or boards. Scrum Backlog behaviour that could not be disabled on existing Scrum boards was avoided by creating a non‑Scrum/Kanban board, copying relevant settings and populating it with the same issues so the Backlog was absent. Status-to-column and column mapping failures were corrected by aligning workflows and statuses or adding required statuses; specialist Jira administrators implemented requested workflow changes and applied provided status mappings when users lacked permissions. Where users could not perform required moves, support moved issues on their behalf or added users to the necessary project roles. Requests needing Jira Service Management functionality were handled by creating new JSM projects and configuring portals, request types, fields and agent teams, and by migrating or linking issues from software projects while retaining requested Kanban boards. Shared/global schemes, custom fields, screens and Versions that blocked project-level changes were detached, recreated or migrated where safe; global changes (for example creating global custom fields, changing issue-type hierarchies, or activating/replacing global workflows) were performed by specialist admins. Custom fields and contexts were created or standardised (including documenting field IDs and contexts), option lists normalised, and system/custom fields adjusted as required. Automation and Advanced Roadmaps (Plans) issues were addressed by reassigning rule ownership and actors so rules executed correctly; where a central/top-level representation was required, support implemented board-level automations to auto-create central top-level items from epics, mapped standard fields (with defaults where source fields were missing), and designated the central board as the Plan top-level source. Bulk imports and migrations were completed by mapping source columns to fields, creating required custom fields and priorities, and performing CSV imports; third-party backlog-prioritisation apps were tested in sandboxes where available and templates recreated or noted when admin installation was required. Project-level metadata changes and Confluence space access issues were handled by verifying product access, directory membership and license assignment, inviting users where allowed, and instructing space owners/admins to add users to space permission schemes when sharing did not grant access. Out-of-scope requests were closed as "won't do" and platform defects or sporadic issues were escalated to Atlassian when required. In one production-to-sandbox copy, support completed the environment copy and granted access to service accounts and users, and observed that customfield IDs in the new sandbox did not match production. Because existing Power Apps / Dataverse flows mapped Jira fields by customfield-ID, the flows could not be reused until mappings were updated; support documented the sandbox field IDs/contexts, recreated or standardised custom fields where appropriate, and reconfigured the integrations or mappings so flows worked against the sandbox environment.

Request‑type, portal and routing faults were resolved by reassigning impacted projects to a dedicated Issue Type Scheme and re‑associating that scheme with affected service projects; teams repaired renamed request‑type JQL, saved filters and dashboard widgets or remapped projects so boards and dashboards returned issues. Mailbox‑forwarding and email‑to‑ticket failures were repeatedly traced to account classification, approved‑domain/SSO interactions and mailbox routing: addresses that existed as Atlassian‑managed approved‑domain accounts were reclassified or recreated as Jira customer accounts; shared mailboxes were represented as dedicated customer/service accounts or routed service mailboxes; and agent licenses were assigned so replies posted as public comments visible to customers. Example remediation used when converting a shared mailbox into a service mailbox included creating a copied service project, migrating the portal form, assigning the mailbox owner as a project admin, routing email into the project via a dedicated mailbox, and assigning agent licenses so outbound replies behaved as expected. Where outbound mail to external recipients failed, investigations included mail logs, SMTP/outgoing mail server settings, and plugin ownership (MS235); teams escalated plugin or relay issues to specialists, confirmed that properly configured service mailboxes could send externally, and clarified that external recipients do not have to be created as agents simply to receive mail, though sender identity and license choices affected send-as behavior. Auto‑reply/acknowledgement behavior was adjusted by changing customer notification/automation rules; intermittent missing creation notifications had correlated with differing automation/assignment senders and were resolved by aligning automation sender identities or centralizing outbound mail through a routed service mailbox. Confluence KB issues surfaced as an interaction between Confluence page restrictions/space permissions and Jira Customer Access: making pages viewable by the Customer Access principal (or removing restrictive page restrictions) and verifying the application link and permission scope restored portal access and search visibility; where changes did not propagate immediately, a Confluence reindex/cache refresh resolved remaining cases. Customer‑selection, CC and scoped searches returned empty results when organization and permission scopes were narrow; expanding the Customer Permissions search scope, ensuring organizations existed for scoped searches, and converting affected users to agents (with licenses) resolved lookup and visibility defects. Moving or cloning Service Management issues into non‑Service‑Management projects had repeatedly caused loss or misrouting of customer‑visible comments; mitigations used included keeping request threads in the originating service project, granting agent access in the destination project, duplicating/cross‑linking issues with structural controls, or encoding customer threads as linked issues so visibility and notifications persisted. Mobile and app client limitations were documented: mobile clients sometimes omitted required request fields and did not expose full agent/admin views or full timeline/history; teams implemented field‑level and automation workarounds or used browser/agent workflows for tasks requiring full views. For shared‑inbox style workflows and presentation requirements (for example Case ID prefilling, Standort autofill, Eingangskanal capture, overdue flags and colorized rules), teams implemented custom fields, SLA/automation rules, or marketplace apps and recorded where behaviors required scripted automations or app capabilities rather than built‑in features. For integrations with external ticketing workflows that include external ticket numbers in subject lines (for example the Cyberstack auto‑reply pattern), teams routed mail through a dedicated service mailbox, configured mail handlers and subject‑matching or automation rules to capture external ticket IDs into comments or custom fields and to correlate replies to the originating Jira issue. Reindexes, cache refreshes and dashboard filter updates were performed where required to propagate configuration and dashboard changes. Tenant‑wide changes that altered default comment visibility were reverted where necessary so comment visibility returned to customer‑visible. Where automations, client limitations or third‑party integrations could not be fully remediated, teams documented the limitation and used operational mitigations (manual workflows, duplication/cross‑linking, scoped visibility controls, or app integrations) to preserve customer experience and traceability.

Project- and board-level configurations, issue type schemes and permission settings were audited and corrected so issues could be created, assigned and routed as expected across company- and enterprise-managed projects. Missing or invisible fields (for example Priority, Start date, Due date, Acceptance Criteria, Business Unit, Contact Person, Labels and Story-Point Schätzung) were restored to edit screens and issue layouts and per-user hidden fields were repinned where required. Missing or misspelled custom-field option values and multi-select lists were added or corrected and option ordering was adjusted. Projects that lacked expected issue types or had disabled types had their Issue Type configuration updated and missing types added so hierarchical relationships (for example Stories under Epics) and manual issue creation worked again; in one case Jira administrators restored creation capability for enterprise-managed boards that had been blocked and confirmed integrations (Teams Jira plugin) regained functionality after issue types and permissions were fixed. Company-managed projects were confirmed to inherit global schemes; requested company-managed boards and issue-type hierarchies for Advanced Roadmaps (Plans) were created and tuned to match reference projects. Automation and clone failures were resolved by aligning rules to the exact custom fields used by each project, adding missing option values referenced by rules, correcting rule conditions and cloning settings after inspecting Automation for Jira audit logs, and adjusting cloning behavior when description content was not copied. Automations that targeted people were updated to point to current dispatchers to avoid routing to unavailable users; an automation that automatically declined or closed approval tickets when the approver field was empty or the selected approver was unavailable was edited so approvals no longer auto-closed unexpectedly and affected tickets were corrected. Approval-routing problems caused by external HR-system sources (Workday) were investigated and reconciled with connector/owner teams (wd-support) so cost-center-to-approver mappings and syncs reflected intended approvers; where approver assignments remained sourced externally the behavior and ownership were documented for requesters. Status, workflow and resolution definitions were updated and transitions were renamed or remapped to restore expected flows; requested waiting statuses were added into workflows and transitions/post-functions were fixed so users could move issues out of waiting statuses to In Progress or Done. Resolution selection was enforced where required by adding validators/post-functions, and automations were configured to trigger on specific resolution values when requested. Permission schemes and issue-level security were updated to restore appropriate visibility; reduced-permission roles (read-only, comment-only and restricted roles) were created and mapped to project permissions and group/role mappings so users could be set as assignees without granting full Assign Issues permission when requested. Requests for elevated admin rights were evaluated case-by-case and, where appropriate, project-specific custom fields and layout changes (for example adding Story-Point Schätzung) were applied instead of granting global admin rights. Confluence template issues were resolved by identifying space owners, confirming template permissions, and creating templates in the space's Templates area after permissions were granted. Remaining project-type limitations (for example team-managed projects lacking Components and company-managed projects not supporting pre-populated Description fields; Forms availability limited to Jira Work Management and Jira Service Management) were documented and communicated. After these changes, fields, issue types, templates, automations, workflows, resolutions and permissions behaved as expected and integrations that had failed to create issues resumed normal operation.

Vendor catalogs (for example Patch My PC) were used where available and custom Intune/SCCM installers were produced with Advanced Installer (Architect) when catalogs lacked entries. Applications, installers and virtualization tooling were published to the Company Portal for organization-wide availability; published examples included MongoDB, SWI‑Prolog, Salesforce CLI (sfdx), Visual Studio Community 2022, PostgreSQL, a Rust 1.82.0 MSI, preconfigured VM images for courses, and the JetBrains_PyCharmCommunityEdition2024 package for PyCharm Community Edition (no license required). When packages were corrupted or failed to start (for example Visual Studio or Visual Studio Code), running the full installer as an overlay/repair restored the application, recreated missing ComponentModelCache folders, and refreshed the Company Portal listing. Unexpected removals during package-version updates (example: Git removed during an update) were resolved by reinstalling the package from the Company Portal to align clients to the published package. Installer hangs or elevation prompts (notably for C++ workloads) were mitigated by IT provisioning required components for users or by delivering tooling inside preconfigured VMs (VirtualBox, VMware, Hyper‑V, or WSL‑based images) to avoid host elevation. Large installers that failed over unstable/mobile connections were redistributed via the Company Portal with cached/offline distribution so clients could obtain full installers without relying on metered networks. macOS prompts for administrator credentials were temporarily mitigated by enabling elevated privileges via the Self Service '3 Jahre Admin' option for affected users. Toolchain and dependency gaps were remediated when they caused installs to fail: Rust MSI failures traced to missing Visual C++ Build Tools (manifesting as 'link.exe' not found) and absent cmake required to build rustup were provisioned so installations completed. Microsoft Defender verification or blocking of downloaded MSIs was addressed by redistributing affected installers via the Company Portal or republishing packages. WSL-dependent tooling (notably Docker Desktop) failed when WSL components were missing, corrupted, or outdated; impacted systems were returned to a usable state by repairing or reinstalling WSL. Docker packaging, permission assignment, and license approval via the IT Self‑Service Portal and Docker Hub required specialist intervention and introduced additional delays. When IDE plugins failed because the packaged IDE was incompatible (example: Copilot4Eclipse failing to install into an older Eclipse), the packaged IDE was updated in the Company Portal and redeployed; users were then able to install the plugin. Company Portal listings typically surfaced within ~15 minutes, though group or license provisioning and per-user assignment sometimes required up to ~24 hours. Availability and access problems were frequently caused by ambiguous or underspecified software requests, incorrect product selection, or unclear approver selection, which could delay requested versions by days or weeks. Package metadata sometimes contained operational details that resolved user issues: for example, the PostgreSQL package description included the default 'postgres' password used by pgAdmin, and MySQL Workbench packages were documented as client-only (no MySQL server included), clarifying that a separate server install was required. Users were informed when requested packages were published and any license/assignment implications (for example community editions requiring no license).

Access and provisioning problems were resolved by confirming which tooling was in-scope for the project, surfacing SSO entitlements, and routing repository- or team-level changes to DevOps for org/team permission grants or manual cleanup. Okta issues were resolved by enabling accounts and waiting a short propagation window (typically 5–10 minutes) before retries restored group assignments and repository access. GitHub membership and team-management problems were resolved by escalating to DevOps and granting appropriate org/team permissions; enterprise-managed invitation failures were treated as membership or policy restrictions. CI/GitHub Actions failures tied to billing, spending limits, failed payments, free-plan limits, or legacy billing were escalated to billing owners or required repository migration. Cloud SaaS invitations (including ChatGPT/OpenAI) were re-sent after Automation for Jira approvals and delivery were confirmed; one case required correcting an incorrect approver on a Jira workflow before an invitation arrived. Licensed IDEs (JetBrains, Visual Studio) were provisioned via the Software Catalogue/Automation for Jira with supervisor and cost-center approvals, products were assigned in vendor admin portals and invites sent; PyCharm Community required no paid license and was installed by 1st Level Support on request. Figma access and Dev Mode were restored by assigning paid/full seats through Okta or the Self Service Portal and sending organization invitations. SonarCloud access was restored by adding users to the SonarCloud organization and having them re-authenticate; support cases documented a critical account-linking nuance where a user’s email could be tied to only one SonarCloud account (for example Bitbucket-linked vs GitLab-linked), requiring administrators to reconcile or add the correct account. GitLab account conflicts were resolved by DevOps manual cleanup and reconciling duplicate or legacy accounts when users authenticated but could not see their data. Unified Endpoint/GCD API keys were restored when a Unified Endpoint record was saved and the platform auto-generated a key tied to the created bot and cost center; Teams support handled failed auto-generation cases. Postman install failures were attributed to missing enterprise admin rights or installer restrictions rather than absent service licenses; successful access followed confirmation of an existing Developer license and a successful download. Workstation installation and privilege problems were resolved either by using the enterprise Company Portal to install without local admin rights or by provisioning admin credentials via a separate ticket; PATH and interpreter issues (for example a Python installer that had not updated PATH) were corrected after installation or with admin access. Remote support sessions (TeamViewer) were used to install and validate developer tools when local installation was required (examples included installing OpenJDK 11 and Workday Studio). UiPath provisioning requests were handled by specialist teams and required explicit runtime, integration, OS, .NET, Office, browser, VM sizing, AD/Kerberos/Okta and storage details. Cloud project provisioning included creation of Supabase projects and separately billed micro-compute instances with approvals and cost metadata recorded. Procurement-style software requests were routed to the Applications & Requirements team for processing; one case showed that team provisioning and approving PyTorch and TensorFlow access for a named academic program. Requests for cloud IDEs or online code-hosting platforms (for example Replit) were routed to specialist and security review because reviewers documented concerns about server-side code hosting, deployment responsibilities, vulnerability tracking, and code-exfiltration risks; those requests were recorded and processed through the application-approval workflow. Ticket records consistently captured platform and permission details plus relevant cost-center or approval metadata, and support clarified ticket status and scheduled installations per user availability when requested. For a GitHub Education-specific case, staff documented that GitHub's verification process required submission of academic-affiliation documents (live webcam verification or uploaded proof) and that an institutional email alone was insufficient; no concrete technical resolution was recorded in that ticket, and alternatives discussed included confirming IU's Campus Program membership and using the IU GitHub Organization for classroom repositories.

The root cause was that the Teams/external-directory groups either were not represented as Atlassian product-visible groups or their directory entries (names/case or membership source) did not match the product group objects Confluence searched. Additionally, Teams shared channels were identified as a source of membership mismatch because shared-channel participants are not always represented as an Azure AD group object and therefore were not included by directory sync. Resolution actions in the ticket set included: re-provisioning or mapping the source groups so they existed as Atlassian product groups (Confluence-visible groups); adjusting the directory-sync/provisioning mapping so group entries and casing matched the product group names; and for Teams-backed groups ensuring the authoritative membership came from an Azure AD group (or creating explicit AD groups/dynamic groups) so membership synced correctly. After re-creating/mapping the groups and re-syncing the directory, the groups became discoverable for @mentions and usable in page restrictions. A request to permission-couple Confluence spaces to Jira projects was noted as a separate concern and was not part of the group-sync remediation above.

The Power Automate trigger was changed from a Shared Access authentication mode to anonymous, which removed the DirectApiAuthorizationRequired failure. It was noted that changing the trigger authentication regenerated the trigger URL; the automation rule was updated to use the new URL and subsequent Jira Automation posts succeeded.

Incidents were traced to multiple distinct causes and resolved with targeted changes and clarifications. One root cause matched a known Jira Cloud bug where Resolution was not reliably set when issues moved to finished statuses and where certain statuses had been assigned to the Done statusCategory (for example an ON HOLD status incorrectly mapped to Done), which caused issues to vanish from boards after a delay. For affected projects workflow and automation changes were applied so Resolution was explicitly set when issues transitioned to done statuses (implemented as an automation rule or workflow post-function), board statusCategory mappings were corrected or board filters were adapted so non-final statuses were not treated as Done, and already-closed issues were backfilled to populate Resolution values so reports and backlog/board displays aligned. Team-managed sprint completion failures were traced to column-to-status mapping: the sprint-complete logic relied on the Done column being the rightmost column, and restoring the Done column to the rightmost position restored correct sprint-complete counts. Separately, the platform behavior that Jira Cloud automatically hid issues that had been closed for more than two weeks from board views (those issues remained accessible via List or Issue views and were not archived or deleted) was documented and explained some disappearances. A new observed symptom — backlog issues and their issue keys appearing struck-through — was identified as a UI indication that the issues had Resolution = "Done". A separate swimlane rename error was reported in one project but lacked diagnostic details and no resolution was recorded; that item was routed to the Jira team for further investigation.

The root cause was incorrect authentication formatting when calling the Jira Cloud REST API from external tools (including Power BI). The issue was resolved by generating a new Atlassian API token and authenticating REST requests with HTTP Basic authorization: the Authorization header contained the base64-encoded string of email:api_token and targeted the REST endpoint (for example, /rest/api/3/search). For Power BI integrations, support provided a PowerQuery function that set the same Authorization header and used Web.Contents to call the Jira REST API; after regenerating the token and using the Basic Authorization header in direct REST calls and in the PowerQuery-based Power BI queries, API requests authenticated successfully. The customer was also informed that paid marketplace connector apps were not available for installation in their environment, which was why a direct REST/PowerQuery approach was used.

A full export of the Insight/CMDB location schema (Insight object typeId=17) was used to reconcile missing and incorrect site/location records. Numerous absent or stale addresses and site entries were identified and either created or updated with canonical fields (Name, Site Manager, Location Code, IT‑Region, Address) so asset-lookup logic and dashboard filters recognized them — example addresses included Schweinfurter Str. 9 (IU Würzburg), Fliethstrasse 67 (Mönchengladbach), and others. A new campus entry for IU Köln (Hildeboldplatz 20) was created while obsolete entries were planned for removal after employee reassignments. Separate work uncovered two additional Location ID gaps (IU Bonn Baunscheidtstrasse 17 and IU Köln Breite Strasse 80‑90); those missing Location IDs were created by the specialist team and confirmed. One location option (Breite Straße / Köln Quincy) had been entered under a different parent group ('IUG Köln') so it did not appear under the expected 'IU Köln' selection; users were able to create tickets by selecting the group where the location was recorded while the grouping was reconciled. Approval workflow failures were traced to empty AtlassianUser attributes on employee/asset records used to link Workday approvers to Jira; populating those AtlassianUser fields restored approver linkage and stopped auto‑cancelling. After the CMDB reconciliation, Location ID creation, grouping fixes and attribute corrections, incoming MEAs and Jira issues were assigned correctly and began appearing on regional dashboards.

The STARTA template logic was modified to separate out Pearson VUE sittings so those exam records were excluded from the affected student exports. The user re-ran STARTA from the Bulk Request screen to produce the corrected outputs and released the correct STARTA entries. Support removed the incorrect overnight-generated STARTA run from the system.

Project automation was enabled and an automation rule was created that used a comment-based trigger scoped to issues in non-active statuses (examples: Closed/Resolved or a custom 'Waiting for customer' status). The rule optionally checked that the commenter was a customer rather than an agent, and executed a workflow transition action to move the issue to the desired active status (for example Reopened or In Progress). Where a new intermediate status was required, the project workflow was updated to include the 'Waiting for customer' status with transitions adjacent to In Progress so the automation transition was valid. After these changes, customer comments caused closed requests or issues in the waiting state to transition back to the configured active status as expected.

The issue was resolved by reinstalling Docker Desktop from the Company Portal. The reinstallation replaced the existing Docker Desktop 4.38.0 installation and restored normal launch behavior; the prior manual edit to settings.sore.json had not fixed the problem.

Multiple distinct Twilio UI failures were observed and resolved by separate actions. Login page rendering/authentication failures were resolved by directing users to the tenant-specific Flex login URL (the “Chihuahua” topaz URL), which allowed successful authentication. Several cases where channel elements (WAPP/IB labels, toggles) or Cases UI controls were invisible or unclickable returned to normal after placing an outbound call from the affected account; this action restored channel visibility and clickability in those incidents. The Cases Transfer button visibility issue was escalated to developers and resolved by a developer-side fix; support confirmed the developer deployment restored the Transfer button. WAPP Templates frontend failures — including an unresponsive send arrow and non-editable fields observed in Microsoft Edge — were fixed by frontend bugfix deployments that restored template selection, the send control, and editable category functionality. Situations where templates appeared empty in the Twilio composer while visible in Salesforce were traced to users selecting the wrong template location; selecting the appropriate Case template location made templates appear without configuration changes. Repeated session expirations, forced logouts during active calls, and intermittent web-page crashes were associated with browser or network instability in affected environments; clearing browser cache and cookies did not permanently resolve these incidents and the problems were escalated for deeper investigation, with no permanent remediation confirmed for those instability-related symptoms. Some persistent page-loading incidents resolved spontaneously with no further corrective action recorded.

Root cause: custom fields created or populated by third-party integrations (user-picker fields, app-managed design fields, etc.) were not always exposed in a form Automation or external Flow could resolve. In many cases the field value existed only as a partial object (for example accountId/displayName with an empty emailAddress), was stored or managed outside the standard clonable payload, or the integration marked the field as read-only or excluded it from outbound/clone payloads. What was done: - For Jira Automation send-email failures, a separate Automation-visible user-picker field was populated (via Advanced JSON) so Jira Automation could resolve a valid recipient; this allowed the Send email action to accept the user as a recipient. - For an external termination Flow that lacked the manager, the Flow was modified to accept the manager field and Jira was updated so the manager field was included in the payload sent to the Flow; after these changes the Flow received the manager and completed the process. - For the Figma integration, it was determined that the Figma-managed design custom field was controlled by the integration and was not clonable or writable by Jira Automation; the issue was closed as a limitation (decision: Won't Do) because the integration did not expose the design data in a way Automation could copy or set. Observations: app-populated custom fields may not appear in the 'Edit work item fields' picker, may lack fields expected by automations (for example emailAddress on user objects), may be excluded from clone or outbound payloads, or may be read-only. Where possible, issues were resolved by copying values into an Automation-accessible field or ensuring the field was included in the outgoing payload; where an integration managed the field and did not expose it, no automation-based fix was possible.

Stakeholders evaluated feasibility, licensing and governance and decided not to adopt Jira Product Discovery under the site's current constraints. A Jira expert confirmed Product Discovery would require paid user access given the tenant's license configuration (three free seats and site admins counted as users). The review documented that Trello lacked sufficient feature depth for backlog/roadmap/priority workflows and that adopting paid external product-management SaaS (Productboard, Aha!, Monday.com, Asana) would introduce new licensing costs and integration overhead with Jira/Confluence. Separately, a Jira Marketplace add-on (com.alignokr.jira) was installed and tested in a sandbox instance; testing showed the add-on was a global installation that could not be scoped per project, altered the UI across all projects, and raised data-protection/privacy concerns for sensitive content. As a result of licensing scarcity and add-on scoping/privacy constraints, the organisation chose not to pursue Product Discovery or that Marketplace add-on in the current environment and recorded alternatives (including evaluating non-Jira options such as Power BI for OKR reporting) for future consideration.

A Power Automate cloud flow was created and executed inside the Power Apps solution "Academic Teacher- Skillset" to update the Employee ID consistently across the three affected Dataverse tables. The flow (located in the solution: https://make.powerapps.com/environments/default-f419c9fe-f7b0-4d87-bee8-e8dfb2190cab/solutions/09ace352-6d58-ee11-be6f-0022489db1eb/objects/cloudflows/c4fb2321-d75a-4068-a587-e3614a3e322a/view) updated the records and resolved the outdated ID display in Skillsmap.

Issues were resolved by ensuring the Jira-side app/plugin was actually installed and enabled at the correct scope and by completing any vendor- or organization-level activation steps required after an OAuth redirect, rather than relying on the redirect alone. Representative resolutions included: • Testmo: com.testmo.jira.connect was installed into the Jira sandbox and the sandbox URI was used on the Testmo side; after installing the app into the site and finishing admin-level configuration under Apps > Manage your apps, Testmo recognized the configured integration and Jira actions worked. • QA Service for Jira (Test IO): the Jira project was activated for the plugin and the requester configured synchronization and field mappings inside the plugin; automated status sync functioned afterward. • Lucid (Lucidchart/Lucidspark): an organization administrator enabled the account-level Lucid–Jira integration and then the user activated the integration on their board; Jira ticket linking worked once both levels were enabled. • Microsoft Viva Goals for Jira: linkage completed only after a Jira administrator installed the Marketplace app on the customer’s Jira Cloud site and finished admin-level setup; attempts failed when the support agent lacked Jira admin rights or when the customer’s site was Jira Data Center while the Marketplace app targeted Cloud only. • Microsoft Teams integrations: a project-level connection attempt failed because tenant-level permissions/tenant app-acceptance prevented the project from connecting; the tenant restriction was confirmed and a workaround using Jira Automation to send updates to Teams via incoming webhooks provided equivalent notifications. • GitLab (GitLab.com for Jira Cloud): the Marketplace app had been installed by a Jira admin but the integration did not appear to the requester until Jira-side configuration was completed; the final step required creating and adding a GitLab token in Jira per GitLab documentation, after which the integration became visible and usable.

Ownership, permissions and notification sources were investigated and actions taken according to findings. When owners lacked permission to delete a company-managed board or project, requests were escalated to administrators or the requester was informed that higher privileges were required; where deletion was approved and possible, the specialist team removed the Jira project, service board or customer portal from the Atlassian Cloud instance (careerpartner.atlassian.net) and confirmed they no longer existed. Customer-facing portals or pages were temporarily restricted while related content and ownership were verified, and associated Confluence spaces were identified and archived or removed when appropriate. The risk of deleting similarly named boards or portals was assessed before removal. If retention holds, audit comments or other blocking conditions prevented deletion, the request was closed as "Won't Do" and the requester was informed. For cases where users continued to receive notifications after a board was decommissioned, notification sources (for example filter subscriptions, automation rules, watchers or other subscriptions) were investigated and offending subscriptions or automations were removed or the affected users were unsubscribed; if notification noise persisted until the project could be deleted, access to the portal was restricted to stop further incoming requests. Outcomes were confirmed by verifying that the project/board/portal and active notification sources no longer existed or were disabled.

The solution import from the Sandbox to the IU production environment was performed after confirming the Column Level Security toggle in Sandbox. The new care_program_id column was added to TableUPSFormatData and a Column Security Profile was created and assigned as required. Column-level permissions for the two remark fields were changed as requested (TabelleUPSProgramData.remark set to read-only; TabelleUPSFormatData.remark set to read+write). Post-import validation used representative test accounts to confirm the updated dropdowns, the new column presence, and the applied column security behaved as expected with no runtime errors.

User authentication was restored by recreating the Twilio worker using the updated corporate name and worker attributes, which fixed the login failure. The subsequent call connection failures (Error 45301) were identified as a Twilio service-side incident; normal call functionality returned after Twilio cleared the outage and Flex Insights indicated the issue was resolved. Post-incident validation confirmed users could place calls and create contracts once the Twilio incident status was cleared.

Evaluations found native Jira did not provide the required-depth reporting: it could not produce planned-vs-actual effort at Story/Epic level, export detailed per-user time logs with issue and parent Epic context, or aggregate/sum custom numeric fields across issues or projects. A Marketplace time-tracking add-on delivered the necessary planned-vs-actual reports and detailed time-log exports, but it could not be scoped to individual projects and it altered the Jira UI across all projects, so it was not adopted. Attempts to use Jira as a replacement for a Monday board failed because Jira lacked built-in dashboard-level summing of custom numeric fields; Backlog Prioritization and Automation for Jira did not provide numeric aggregation on dashboards without paid apps. Additional KPI/dashboard requirements were identified (time-range filtering, person-based ticket counts for a period, and conditional status exclusion by request type); these requests were escalated to specialists and support provided guidance links and suggestions (including using AI assistance) but no implementation was completed due to resource constraints. In summary, native Jira lacked the needed export, per-user visibility, filtering, and aggregation capabilities, and available Marketplace apps met functional needs but introduced scope and UI impacts that prevented selective rollout, so no scoped, out-of-the-box solution was implemented.

The Miro-Jira integration was reconfigured to enable bidirectional synchronization following Miro's Jira integration documentation. Bidirectional sync was turned on and the configuration was verified; Jira updates were subsequently pushed into Miro and changes now flowed both directions.

Requirements and a pilot scope were documented: question counts per module, collaborative editing and comment controls, non‑destructive handling of questions, manual copy/export needs, and a future roadmap for automated exam generation/grading. Excel was considered for alignment with current templates and security needs were explicitly recorded. No production solution was deployed during the pilot documentation phase and implementation decisions remained pending.

A consolidated Jira intake pattern was established, documented, and implemented for multiple use cases, and alternatives and constraints were recorded to guide future intake choices. For video production the IVT Work Management project hosted an Atlassian Forms request form; submissions were mapped to create issues on the IVT board and notifications were configured to alert the video team. Embedding a Jira Issue Collector in Confluence via an HTML macro was evaluated and documented as an alternative; the requester chose to create tasks in a separate browser tab but both options were recorded as viable, trackable patterns. Existing Microsoft Forms + Power Automate pipelines were reviewed; for CMS intake the pipeline was retained and a dedicated CMS Jira project was confirmed as acceptable after assessing cross-unit visibility and handover constraints. For EPOS intake an IT Service Portal form was configured to map free-text fields to the EPOS Jira project, set the issue type to "bug," and assign requested label(s); that mapping was tested and confirmed. For a high-volume support team (Team Lehrformate) Jira / Jira Service Management (service-portal or team project) was recommended and implemented; SharePoint was judged unsuitable for the expected volume, and MS Forms + automation using tools such as MAKE (Integromat) remained a documented alternative for team-managed pipelines. Guidance about form ownership and portal behaviour was provided: teams that host forms in their own Jira project retained full control over form design, while forms hosted inside the central IT Service Portal required coordination and agreement on design; portal tiles could link to other projects but the design/ownership and resulting visibility/licensing implications depended on where the form was created. All viable intake mechanisms (project Forms, Issue Collector, IT Service Portal forms, and existing Forms+automation pipelines), the decision to create dedicated projects where appropriate, and access/licensing/visibility/privacy constraints (including agent-license and handover considerations) were documented to guide which intake mechanism was appropriate for each use case.

Investigators reviewed the affected Automation for Jira rules, triggers and JQL and found multiple distinct causes that were corrected. Reminder actions had been tied to the same time-based condition as the autoclose action; reminder logic was separated from autoclose triggers so 5‑day approval reminders ran independently. Several approval failures were traced to approver records: some approvers were departed/unavailable and some cost‑center approver lookups failed for specific user accounts. Stale or incorrect approver records and cost‑center mappings were corrected or removed, and the approval-selection logic was adjusted so cost‑center approvers resolved reliably (restoring automated approver assignment for affected users). An unrelated automation rule that had been deleting the component field after it was set was changed so it no longer removed the component; this restored correct routing to the Business Operations queue. The autoclose JQL was validated and standardized to approvals = pending() AND updated <= endOfDay(-14d) so autoclose ran only after 14 days with no updates. Support confirmed that users seeing a "No access" message were opening requests that had already been approved or closed, and therefore the approval UI was not available for those requests.

The Marketplace listing was checked and it was confirmed that the requested PlantUML app is published only for Confluence Server/Data Center and has no Cloud-compatible variant. Because the add-on did not exist for Confluence Cloud, the activation request could not be fulfilled and the request was closed as not-available for the Cloud site.

The Applications & Requirements team applied the required project- and board-scoped issue-type configuration updates. They added requested new types (for example, 'Milestone' to projects LP, APP, TF, IDSS and 'Quality-Task' to the affected board), removed deprecated types ('Quick-fix Task', 'Standort-Task') from the board configuration, and migrated existing issues from removed types into the replacement issue type. After the configuration and migration the new issue types were available for selection on the affected projects/boards and the moved issues reflected the new classification and statuses.

The board's configuration and permission scheme were compared with a working board, discrepancies were identified, and the board settings were adjusted to match the working configuration. After the configuration change the user was able to close sprints on that board and confirmed the issue was resolved.

A mail handler and mailbox were created and attached to the FSCMS project so incoming emails were converted into Jira tickets; mailbox routing/forwarding was configured to deliver emails to Jira. Investigation found that the Mail Handler’s configured error-path forwarding (visible via German-localized messaging) was triggered when an incoming sender lacked the required project permission to comment; that permission error caused the handler to follow the error-handling branch and forward a copy to the Academia administrative address. Correcting the sender’s project permissions, or ensuring messages were processed under the configured default-reporter behavior, removed the permission error and stopped the unexpected error-path forwarding.

Form-driven sub-task creation and empty/overwritten field incidents were resolved by correcting Automation for Jira rules and integration behavior so submitted form values were preserved and new issues were created with the proper parent and fields. In one resolved case the automation rule was updated to evaluate exact custom field IDs and compare their literal values using smart-values (for example customfield_13856 and customfield_13858 checked against the literal "Yes"); the Create issue action produced Issue Type = Sub-task, Parent = {{issue.key}}, Component = Infrastructure, and populated Summary with the intended templates ("Win11 - Network drive", "Win11 - Local services"). A separate class of incidents—in which created issues arrived with empty Description or missing yellow-marked form fields—was traced to an automation rule that ran after creation and overwrote the Description; affected tickets were intermittent and produced no error codes. Those cases were mitigated by disabling or correcting the post-create automation/edit actions so they preserved non-empty form inputs (a temporary workaround observed was reopening the created issue and re-entering the form fields, which then displayed and saved correctly). For external-event-driven sub-task requirements (for example Workday failures) implementations documented included creating sub-tasks via the Jira REST API (setting the parent field), using Automation for Jira with an incoming webhook trigger, email-to-Jira, or a middleware/iPaaS to translate events into Jira API calls. All solutions required the target project to have the Sub-task issue type enabled and the automation/integration actor or credentials to have permission to create sub-tasks.

Support identified these incidents as an upstream Atlassian platform/service outage after confirming Okta SSO continued to authenticate successfully, indicating local SSO or credentials were not the root cause. The outage affected Jira, Confluence, the Atlassian/IT Service Portal, and integrated apps such as Automation for Jira, and manifested as generic errors, blank pages, login failures, and unexpected redirects. Atlassian restored the platform services; access typically returned after the vendor recovery (some users observed that waiting a few minutes and retrying resolved the redirect behavior). No local configuration changes or remediation were required, and support verified access was restored for affected users, including those who had attempted password resets.

Incidents were resolved by reinstalling Visual Studio Code. In one company-managed case the application was uninstalled and reinstalled through the Company Portal (the reinstall sequence was performed twice), after which VS Code opened normally; that incident was attributed to the Company Portal update state preventing startup. In a separate Windows 10 case a user-performed fresh installation of VS Code also restored normal startup after prior restarts had not helped.

Support advised that the internal team only handled new account creation and directed the requester to Twilio's support/appeal channels for removing or reporting spam/false-positive contact markings. Appropriate Twilio support portals were provided to the requester to resolve the spam flag.

Multiple incidents involved Jira/Automation for Jira approval workflows failing to complete. In one case a raffle/giveaway prize order placed on 2024-12-17 cleared an Automation for Jira approval that had been awaiting action; placing the order cleared the pending state and shipping confirmation with a tracking number was to be sent when the AirPods Max were dispatched. In a separate case a contract-extension request to extend external service provider Laura Steinbach to 2025-12-31 was identified as a mistaken submission; the submitter requested it not be approved and the request was deleted/closed with the resolution set to "Won't Do." In another incident a single user (Judith) saw approvals listed in "My approvals" but opening the ticket produced an error and prevented approval; support intervened and asked the user to retry, after which the approval function worked again. No detailed error codes or technical remediation steps were documented for the UI/access case.

Investigations identified two distinct causes. For duplicate, disappearing, truncated-payload messages and unresponsive UI, redundant Conversation-related and other webhooks were delivering duplicate event deliveries; pruning the unnecessary webhook endpoints removed the duplicate events, restored full TaskSid values in payloads, allowed messages to load and be edited, and resolved the disappearing/duplicate message behavior and unresponsive controls. For cases where the first WhatsApp message sent via Channel Switch was not recorded as 'sent' and did not count toward activity, support observed error traces consistent with the agent not accepting/taking the Task after initiating the Channel Switch; support provided interim guidance to verify Task acceptance when performing Channel Switch and requested full session/troubleshooting logs if the issue recurred. No permanent fix for the Channel Switch/task-acceptance symptom was recorded in the ticket.

Scanned the GitLab group to identify repositories missing metadata.yml and added a metadata.yml to each affected repository containing the required fields (examples used: repository_type: infrastructure, name: aws-client-vpn, team: DevOps). The additions were recorded in the team's GitLab documentation to document the requirement and the changes.

Support confirmed the request had been submitted to the incorrect team and provided the requester with the correct GCD service portal URL (careerpartner.atlassian.net servicedesk portal for GCD access/domain requests). The requester was redirected to that portal and the ticket was closed.

The user was made visible after the required Flex skills were assigned to their Twilio/Flex profile via the Flex administration skill-management interface. After the skill assignment and saving the profile, the user appeared in the Duisburg (B2C) team list.

Atlassian updated the account backend display-name entries to the correct full name. After the backend correction propagated, the user's profile on the service portal showed the updated, correct display name and the issue was resolved.

The notification system's default language was changed to English and the outgoing templates were updated so all notification content was in English. The entry sort configuration was modified to use creation date in descending order so newest items appeared first. The flow/workflow display configuration was updated to surface the flow's on/off status. Project wiki and referenced tool links from the ticket were kept as references.

A short clarification meeting collected the requested layout and field‑mapping details; ownership was moved to an internal service account / appropriate owner and the app was updated. The narrower vertical layout and additional display fields were implemented, the new position fields were mapped to the specified SharePoint list columns (Campus Operations - Führungskräfte On Campus - Alle Elemente), and the app was republished under the new ownership.

The user was instructed to submit the personal-page request through the institutional reporting/service portal (https://careerpartner.atlassian.net/servicedesk/customer/portal/1). The guidance routed the requester to the correct intake process and the ticket was closed after providing the portal link.

The problem was resolved by using Google Chrome and enabling Chrome's 'Memory saver' feature via the browser Performance settings. After enabling Memory saver, Jira and Confluence pages loaded reliably for the affected user.

Developer resources were allocated and a dedicated implementation story was created in the development backlog to build the Handshake <> S3 integration. Stakeholders were granted access to the implementation story to follow progress. The Core Development Team accepted the work and began implementing the integration using AWS S3 and AWS CLI as the delivery mechanism; the original request ticket was closed after resources and the implementation tracking story were assigned.

Support acknowledged the UI-selection anomaly and provided a temporary workaround by advising the user to use the search field to locate the desired software entry. No UI component changes were made in this ticket; the advice was recorded as the support response while the underlying dropdown behavior remained unresolved within the ticket.

Support reviewed the symptom and referred the user to the Syntea application team for investigation of the content-discrepancy in Syntea. No Syntea configuration or dataset changes were performed by support during this ticket; the user was directed to the vendor/application owners for further diagnostics and resolution.

No technical remediation was documented in the ticket. Internal staff requested whether an API key or other credentials were required, but the requester did not respond; the ticket was auto-closed by Automation for Jira after 14 days with no resolution recorded.

IT identified the shared link as an external/public Confluence link and deactivated the public share. The option to integrate/embed Confluence content into SharePoint was also disabled. After deactivating the external link and disabling the SharePoint integration option, the intermittent access errors ceased for affected users.

Two behaviours were observed and recorded. In one case approval requests began appearing normally without intervention; support noted a likely race condition where multi-approver requests became unopenable for one approver after the other approver completed approval. In a separate case the Automation for Jira rule detected a missing approver and automatically declined and closed the ticket (resolution set to "Declined"); no corrective action restored that specific ticket after the automated decline.